Frontend drošība: XSS novēršana un satura drošības politika (CSP)

Mūsdienu tīmekļa izstrādes vidē frontend drošība ir vissvarīgākā. Tā kā tīmekļa lietojumprogrammas kļūst arvien sarežģītākas un interaktīvākas, tās kļūst arī neaizsargātākas pret dažādiem uzbrukumiem, īpaši pret starpvietņu skriptošanu (XSS). Šis raksts sniedz visaptverošu ceļvedi, kā izprast un mazināt XSS ievainojamības, kā arī ieviest Satura drošības politiku (CSP) kā spēcīgu aizsardzības mehānismu.

Izpratne par starpvietņu skriptošanu (XSS)

Kas ir XSS?

Starpvietņu skriptošana (XSS) ir injekcijas uzbrukuma veids, kurā ļaunprātīgi skripti tiek ievadīti citādi labdabīgās un uzticamās vietnēs. XSS uzbrukumi notiek, kad uzbrucējs izmanto tīmekļa lietojumprogrammu, lai nosūtītu ļaunprātīgu kodu, parasti pārlūkprogrammas puses skripta veidā, citam gala lietotājam. Trūkumi, kas ļauj šiem uzbrukumiem gūt panākumus, ir diezgan izplatīti un rodas visur, kur tīmekļa lietojumprogramma izmanto lietotāja ievadi savā ģenerētajā izvadē, to nevalidējot vai nekodējot.

Iedomājieties populāru tiešsaistes forumu, kurā lietotāji var publicēt komentārus. Ja forums pienācīgi neattīra lietotāja ievadi, uzbrucējs varētu komentārā ievadīt ļaunprātīgu JavaScript fragmentu. Kad citi lietotāji skatās šo komentāru, ļaunprātīgais skripts tiek izpildīts viņu pārlūkprogrammās, potenciāli nozagot viņu sīkdatnes, novirzot viņus uz pikšķerēšanas vietnēm vai bojājot vietni.

XSS uzbrukumu veidi

• Atspoguļotais XSS (Reflected XSS): Ļaunprātīgais skripts tiek ievadīts vienā pieprasījumā. Serveris nolasa ievadītos datus no HTTP pieprasījuma un atspoguļo tos atpakaļ lietotājam, izpildot skriptu viņa pārlūkprogrammā. To bieži panāk ar pikšķerēšanas e-pastiem, kas satur ļaunprātīgas saites.
• Saglabātais XSS (Stored XSS): Ļaunprātīgais skripts tiek saglabāts mērķa serverī (piemēram, datu bāzē, foruma ierakstā vai komentāru sadaļā). Kad citi lietotāji piekļūst saglabātajiem datiem, skripts tiek izpildīts viņu pārlūkprogrammās. Šis XSS veids ir īpaši bīstams, jo tas var ietekmēt lielu skaitu lietotāju.
• DOM bāzētais XSS (DOM-based XSS): Ievainojamība pastāv pašā klienta puses JavaScript kodā. Uzbrukums manipulē ar DOM (Document Object Model) upura pārlūkprogrammā, izraisot ļaunprātīgā skripta izpildi. Tas bieži ietver URL vai citu klienta puses datu manipulēšanu.

XSS ietekme

Veiksmīga XSS uzbrukuma sekas var būt smagas:

• Sīkdatņu zādzība: Uzbrucēji var nozagt lietotāju sīkdatnes, iegūstot piekļuvi viņu kontiem un sensitīvai informācijai.
• Konta pārņemšana: Ar nozagtām sīkdatnēm uzbrucēji var uzdoties par lietotājiem un veikt darbības viņu vārdā.
• Tīmekļa vietnes bojāšana: Uzbrucēji var modificēt tīmekļa vietnes izskatu, izplatot dezinformāciju vai kaitējot zīmola reputācijai.
• Novirzīšana uz pikšķerēšanas vietnēm: Lietotāji var tikt novirzīti uz ļaunprātīgām vietnēm, kas zog viņu pieteikšanās datus vai instalē ļaunprātīgu programmatūru.
• Datu eksfiltrācija: Sensitīvi dati, kas redzami lapā, var tikt nozagti un nosūtīti uz uzbrucēja serveri.

XSS novēršanas metodes

XSS uzbrukumu novēršanai nepieciešama daudzslāņu pieeja, koncentrējoties gan uz ievades validāciju, gan izvades kodēšanu.

Ievades validācija

Ievades validācija ir process, kurā tiek pārbaudīts, vai lietotāja ievade atbilst gaidītajam formātam un datu tipam. Lai gan tā nav droša aizsardzība pret XSS, tā palīdz samazināt uzbrukuma virsmu.

• Baltā saraksta validācija: Definējiet stingru atļauto rakstzīmju un modeļu kopu. Noraidiet jebkuru ievadi, kas neatbilst baltajam sarakstam. Piemēram, ja sagaidāt, ka lietotājs ievadīs vārdu, atļaujiet tikai burtus, atstarpes un, iespējams, defises.
• Melnā saraksta validācija: Identificējiet un bloķējiet zināmas ļaundabīgas rakstzīmes vai modeļus. Tomēr melnie saraksti bieži ir nepilnīgi, un gudri uzbrucēji tos var apiet. Baltā saraksta validācijai parasti dod priekšroku pār melnā saraksta validāciju.
• Datu tipa validācija: Pārliecinieties, ka ievade atbilst gaidītajam datu tipam (piemēram, vesels skaitlis, e-pasta adrese, URL).
• Garuma ierobežojumi: Ieviesiet maksimālā garuma ierobežojumus ievades laukiem, lai novērstu bufera pārpildes ievainojamības.

Piemērs (PHP):

<?php $username = $_POST['username']; // Baltā saraksta validācija: Atļaut tikai burtciparu rakstzīmes un pasvītras if (preg_match('/^[a-zA-Z0-9_]+$/', $username)) { // Derīgs lietotājvārds echo "Derīgs lietotājvārds: " . htmlspecialchars($username, ENT_QUOTES, 'UTF-8'); } else { // Nederīgs lietotājvārds echo "Nederīgs lietotājvārds. Atļautas tikai burtciparu rakstzīmes un pasvītras."; } ?>

Izvades kodēšana (Escaping)

Izvades kodēšana, zināma arī kā "escaping", ir process, kurā speciālās rakstzīmes tiek pārvērstas to HTML entītijās vai URL kodētos ekvivalentos. Tas neļauj pārlūkprogrammai interpretēt rakstzīmes kā kodu.

• HTML kodēšana: Pārveidojiet rakstzīmes, kurām ir īpaša nozīme HTML, piemēram, <, >, &, ", un '. Izmantojiet tādas funkcijas kā htmlspecialchars() PHP valodā vai ekvivalentas metodes citās valodās.
• URL kodēšana: Kodējiet rakstzīmes, kurām ir īpaša nozīme URL, piemēram, atstarpes, slīpsvītras un jautājuma zīmes. Izmantojiet tādas funkcijas kā urlencode() PHP valodā vai ekvivalentas metodes citās valodās.
• JavaScript kodēšana: Pārveidojiet rakstzīmes, kurām ir īpaša nozīme JavaScript, piemēram, vienpēdiņas, dubultpēdiņas un atpakaļvērstās slīpsvītras. Izmantojiet tādas funkcijas kā JSON.stringify() vai bibliotēkas, piemēram, ESAPI (Encoder).

Piemērs (JavaScript - HTML kodēšana):

function escapeHTML(str) { let div = document.createElement('div'); div.appendChild(document.createTextNode(str)); return div.innerHTML; } let userInput = '<script>alert("XSS");</script>'; let encodedInput = escapeHTML(userInput); // Izkodēto ievadi izvadīt DOM document.getElementById('output').innerHTML = encodedInput; // Izvade: &lt;script&gt;alert("XSS");&lt;/script&gt;

Piemērs (Python - HTML kodēšana):

import html user_input = '<script>alert("XSS");</script>' encoded_input = html.escape(user_input) print(encoded_input) # Izvade: &lt;script&gt;alert("XSS");&lt;/script&gt;

Kontekstjutīga kodēšana

Izmantotais kodēšanas veids ir atkarīgs no konteksta, kurā dati tiek attēloti. Piemēram, ja jūs attēlojat datus HTML atribūtā, jums jāizmanto HTML atribūtu kodēšana. Ja jūs attēlojat datus JavaScript virknē, jums jāizmanto JavaScript virkņu kodēšana.

Piemērs:

<input type="text" value="<?php echo htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8'); ?>">

Šajā piemērā name parametra vērtība no URL tiek attēlota ievades lauka value atribūtā. Funkcija htmlspecialchars() nodrošina, ka jebkuras speciālās rakstzīmes name parametrā tiek pareizi kodētas, novēršot XSS uzbrukumus.

Veidņu dzinēja izmantošana

Daudzas mūsdienu tīmekļa ietvari un veidņu dzinēji (piemēram, React, Angular, Vue.js, Twig, Jinja2) nodrošina automātiskus izvades kodēšanas mehānismus. Šie dzinēji automātiski pārveido mainīgos, kad tie tiek renderēti veidnēs, samazinot XSS ievainojamību risku. Vienmēr izmantojiet sava veidņu dzinēja iebūvētās pārveidošanas funkcijas.

Satura drošības politika (CSP)

Kas ir CSP?

Satura drošības politika (CSP) ir papildu drošības slānis, kas palīdz atklāt un mazināt noteikta veida uzbrukumus, tostarp starpvietņu skriptošanu (XSS) un datu injekcijas uzbrukumus. CSP darbojas, ļaujot jums definēt avotu balto sarakstu, no kuriem pārlūkprogrammai ir atļauts ielādēt resursus. Šis baltais saraksts var ietvert domēnus, protokolus un pat konkrētus URL.

Pēc noklusējuma pārlūkprogrammas ļauj tīmekļa lapām ielādēt resursus no jebkura avota. CSP maina šo noklusējuma uzvedību, ierobežojot avotus, no kuriem var ielādēt resursus. Ja vietne mēģina ielādēt resursu no avota, kas nav baltajā sarakstā, pārlūkprogramma bloķēs pieprasījumu.

Kā darbojas CSP

CSP tiek ieviesta, nosūtot HTTP atbildes galveni no servera uz pārlūkprogrammu. Galvene satur direktīvu sarakstu, no kurām katra norāda politiku noteikta veida resursam.

CSP galvenes piemērs:

Content-Security-Policy: default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';

Šī galvene definē šādas politikas:

• default-src 'self': Atļauj resursus ielādēt tikai no tās pašas izcelsmes (domēna) kā tīmekļa lapa.
• script-src 'self' https://example.com: Atļauj JavaScript ielādēt no tās pašas izcelsmes un no https://example.com.
• style-src 'self' https://cdn.example.com: Atļauj CSS ielādēt no tās pašas izcelsmes un no https://cdn.example.com.
• img-src 'self' data:: Atļauj attēlus ielādēt no tās pašas izcelsmes un no datu URI (base64 kodēti attēli).
• font-src 'self': Atļauj fontus ielādēt no tās pašas izcelsmes.

CSP direktīvas

Šeit ir dažas no visbiežāk izmantotajām CSP direktīvām:

• default-src: Iestata noklusējuma politiku visiem resursu veidiem.
• script-src: Definē avotus, no kuriem var ielādēt JavaScript.
• style-src: Definē avotus, no kuriem var ielādēt CSS.
• img-src: Definē avotus, no kuriem var ielādēt attēlus.
• font-src: Definē avotus, no kuriem var ielādēt fontus.
• connect-src: Definē izcelsmes, ar kurām klients var izveidot savienojumu (piemēram, izmantojot WebSockets, XMLHttpRequest).
• media-src: Definē avotus, no kuriem var ielādēt audio un video.
• object-src: Definē avotus, no kuriem var ielādēt spraudņus (piemēram, Flash).
• frame-src: Definē izcelsmes, kuras var iegult kā rāmjus (<frame>, <iframe>).
• base-uri: Ierobežo URL, kurus var izmantot dokumenta <base> elementā.
• form-action: Ierobežo URL, uz kuriem var iesniegt veidlapas.
• upgrade-insecure-requests: Norāda pārlūkprogrammai automātiski jaunināt nedrošus pieprasījumus (HTTP) uz drošiem pieprasījumiem (HTTPS).
• block-all-mixed-content: Neļauj pārlūkprogrammai ielādēt jebkādu jaukto saturu (HTTP saturs, kas ielādēts, izmantojot HTTPS).
• report-uri: Norāda URL, uz kuru pārlūkprogrammai jānosūta pārkāpumu ziņojumi, kad tiek pārkāpta CSP politika.
• report-to: Norāda grupas nosaukumu, kas definēts `Report-To` galvenē, kura satur galapunktus pārkāpumu ziņojumu sūtīšanai. Modernāks un elastīgāks `report-uri` aizstājējs.

CSP avotu saraksta vērtības

Katra CSP direktīva pieņem avotu vērtību sarakstu, kas norāda atļautās izcelsmes vai atslēgvārdus.

• 'self': Atļauj resursus no tās pašas izcelsmes kā tīmekļa lapa.
• 'none': Aizliedz resursus no visām izcelsmēm.
• 'unsafe-inline': Atļauj iekļauto JavaScript un CSS. No tā vajadzētu izvairīties, kad vien iespējams, jo tas vājina aizsardzību pret XSS.
• 'unsafe-eval': Atļauj izmantot eval() un saistītās funkcijas. No tā arī vajadzētu izvairīties, jo tas var radīt drošības ievainojamības.
• 'strict-dynamic': Norāda, ka uzticība, kas skaidri dota skriptam marķējumā, izmantojot pavadošo nonce vai jaucējkodu, tiek pārnesta uz visiem skriptiem, ko ielādē šis saknes skripts.
• https://example.com: Atļauj resursus no konkrēta domēna.
• *.example.com: Atļauj resursus no jebkura konkrēta domēna apakšdomēna.
• data:: Atļauj datu URI (base64 kodēti attēli).
• mediastream:: Atļauj `mediastream:` URI priekš `media-src`.
• blob:: Atļauj `blob:` URI (izmanto bināriem datiem, kas glabājas pārlūkprogrammas atmiņā).
• filesystem:: Atļauj `filesystem:` URI (izmanto, lai piekļūtu failiem, kas glabājas pārlūkprogrammas smilškastes failu sistēmā).
• nonce-{random-value}: Atļauj iekļautos skriptus vai stilus, kuriem ir atbilstošs nonce atribūts.
• sha256-{hash-value}: Atļauj iekļautos skriptus vai stilus, kuriem ir atbilstošs sha256 jaucējkods.

CSP ieviešana

Ir vairāki veidi, kā ieviest CSP:

• HTTP galvene: Visizplatītākais veids, kā ieviest CSP, ir iestatot Content-Security-Policy HTTP galveni servera atbildē.
• Meta tags: CSP var definēt arī, izmantojot <meta> tagu HTML dokumentā. Tomēr šī metode ir mazāk elastīga un tai ir daži ierobežojumi (piemēram, to nevar izmantot, lai definētu frame-ancestors direktīvu).

Piemērs (CSP iestatīšana, izmantojot HTTP galveni - Apache):

Savā Apache konfigurācijas failā (piemēram, .htaccess vai httpd.conf) pievienojiet šādu rindu:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';"

Piemērs (CSP iestatīšana, izmantojot HTTP galveni - Nginx):

Savā Nginx konfigurācijas failā (piemēram, nginx.conf) pievienojiet šādu rindu server blokā:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';";

Piemērs (CSP iestatīšana, izmantojot Meta tagu):

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://example.com; style-src 'self' https://cdn.example.com; img-src 'self' data:; font-src 'self';">

CSP testēšana

Ir ļoti svarīgi pārbaudīt savu CSP implementāciju, lai nodrošinātu, ka tā darbojas, kā paredzēts. Varat izmantot pārlūkprogrammas izstrādātāju rīkus, lai pārbaudītu Content-Security-Policy galveni un meklētu jebkādus pārkāpumus.

CSP ziņošana

Izmantojiet `report-uri` vai `report-to` direktīvas, lai konfigurētu CSP ziņošanu. Tas ļauj jūsu serverim saņemt ziņojumus, kad CSP politika tiek pārkāpta. Šī informācija var būt nenovērtējama drošības ievainojamību identificēšanai un labošanai.

Piemērs (CSP ar report-uri):

Content-Security-Policy: default-src 'self'; report-uri /csp-report-endpoint;

Piemērs (CSP ar report-to - modernāks):

Report-To: {"group":"csp-endpoint","max_age":10886400,"endpoints":[{"url":"https://your-domain.com/csp-report-endpoint"}]} Content-Security-Policy: default-src 'self'; report-to csp-endpoint;

Servera puses galapunkts (`/csp-report-endpoint` šajos piemēros) jākonfigurē, lai saņemtu un apstrādātu šos JSON ziņojumus, reģistrējot tos vēlākai analīzei.

CSP labākā prakse

• Sāciet ar stingru politiku: Sāciet ar ierobežojošu politiku, kas atļauj resursus tikai no tās pašas izcelsmes (default-src 'self'). Pakāpeniski atvieglojiet politiku pēc nepieciešamības, pievienojot konkrētus avotus, ja nepieciešams.
• Izvairieties no 'unsafe-inline' un 'unsafe-eval': Šīs direktīvas ievērojami vājina aizsardzību pret XSS. Centieties no tām izvairīties, kad vien iespējams. Izmantojiet nonces vai jaucējkodus iekļautajiem skriptiem un stiliem, un izvairieties no eval() izmantošanas.
• Izmantojiet nonces vai jaucējkodus iekļautajiem skriptiem un stiliem: Ja jums ir jāizmanto iekļautie skripti vai stili, izmantojiet nonces vai jaucējkodus, lai tos iekļautu baltajā sarakstā.
• Izmantojiet CSP ziņošanu: Konfigurējiet CSP ziņošanu, lai saņemtu paziņojumus, kad politika tiek pārkāpta. Tas palīdzēs jums identificēt un novērst drošības ievainojamības.
• Rūpīgi pārbaudiet savu CSP implementāciju: Izmantojiet pārlūkprogrammas izstrādātāju rīkus, lai pārbaudītu Content-Security-Policy galveni un meklētu jebkādus pārkāpumus.
• Izmantojiet CSP ģeneratoru: Vairāki tiešsaistes rīki var palīdzēt jums ģenerēt CSP galvenes, pamatojoties uz jūsu īpašajām prasībām.
• Pārraugiet CSP ziņojumus: Regulāri pārskatiet CSP ziņojumus, lai identificētu potenciālas drošības problēmas un precizētu savu politiku.
• Uzturiet savu CSP atjauninātu: Tā kā jūsu vietne attīstās, pārliecinieties, ka atjaunināt savu CSP, lai atspoguļotu jebkādas izmaiņas resursu atkarībās.
• Apsveriet iespēju izmantot Satura drošības politikas (CSP) linteri: Rīki, piemēram, `csp-html-webpack-plugin` vai pārlūkprogrammas paplašinājumi, var palīdzēt validēt un optimizēt jūsu CSP konfigurāciju.
• Ieviesiet CSP pakāpeniski (Tikai ziņošanas režīms): Sākotnēji izvietojiet CSP "tikai ziņošanas" režīmā, izmantojot Content-Security-Policy-Report-Only galveni. Tas ļauj jums uzraudzīt potenciālos politikas pārkāpumus, faktiski nebloķējot resursus. Analizējiet ziņojumus, lai precizētu savu CSP, pirms to piespiedu kārtā ieviest.

Piemērs (Nonce implementācija):

Servera puse (Nonce ģenerēšana):

<?php $nonce = base64_encode(random_bytes(16)); ?>

HTML:

<script nonce="<?php echo $nonce; ?>"> // Jūsu iekļautais skripts šeit console.log('Iekļautais skripts ar nonce'); </script>

CSP galvene:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-<?php echo $nonce; ?>';

CSP un trešo pušu bibliotēkas

Izmantojot trešo pušu bibliotēkas vai CDN, pārliecinieties, ka iekļaujat to domēnus savā CSP politikā. Piemēram, ja izmantojat jQuery no CDN, jums būtu jāpievieno CDN domēns script-src direktīvai.

Tomēr, akli iekļaujot veselus CDN baltajā sarakstā, var rasties drošības riski. Apsveriet iespēju izmantot apakšresursu integritāti (SRI), lai pārbaudītu no CDN ielādēto failu integritāti.

Apakšresursu integritāte (SRI)

SRI ir drošības funkcija, kas ļauj pārlūkprogrammām pārbaudīt, vai faili, kas iegūti no CDN vai citiem trešo pušu avotiem, nav tikuši mainīti. SRI darbojas, salīdzinot iegūtā faila kriptogrāfisko jaucējkodu ar zināmu jaucējkodu. Ja jaucējkodi nesakrīt, pārlūkprogramma bloķēs faila ielādi.

Piemērs:

<script src="https://example.com/jquery.min.js" integrity="sha384-example-hash" crossorigin="anonymous"></script>

Atribūts integrity satur jquery.min.js faila kriptogrāfisko jaucējkodu. Atribūts crossorigin ir nepieciešams, lai SRI darbotos ar failiem, kas tiek pasniegti no dažādām izcelsmēm.

Noslēgums

Frontend drošība ir kritisks tīmekļa izstrādes aspekts. Izprotot un ieviešot XSS novēršanas metodes un Satura drošības politiku (CSP), jūs varat ievērojami samazināt uzbrukumu risku un aizsargāt savu lietotāju datus. Atcerieties pieņemt daudzslāņu pieeju, apvienojot ievades validāciju, izvades kodēšanu, CSP un citas drošības labākās prakses. Turpiniet mācīties un sekojiet līdzi jaunākajiem drošības apdraudējumiem un mazināšanas metodēm, lai veidotu drošas un stabilas tīmekļa lietojumprogrammas.

Šis ceļvedis sniedz pamatzināšanas par XSS novēršanu un CSP. Atcerieties, ka drošība ir nepārtraukts process, un nepārtraukta mācīšanās ir būtiska, lai būtu soli priekšā potenciālajiem draudiem. Ieviešot šīs labākās prakses, jūs varat radīt drošāku un uzticamāku tīmekļa pieredzi saviem lietotājiem.